Motivation and Context

Just reading code and noticed FreeBSD support for TRIM to file-backed vdevs was commented out. Looked further and found FreeBSD 14 implemented support for it, so for fun I wired it up.

Description

First, rename vfs_file_fallocate to vfs_file_deallocate, and push the Linux-specific hole-punching flags down to the Linux implementation, and make a FreeBSD no-op implementation.

Then, fill out the FreeBSD implementation with calls to fspacectl() (userspace) or fo_fspacectl() (kernel).

How Has This Been Tested?

Compile checked on Linux 6.1, FreeBSD 13 & 14.

On Linux, zpool_trim and trim test tags continue to pass.

On FreeBSD its a little more complicated. Currently UFS doesn't implement a specific VOP_DEALLOCATE, so the generic fallback is used, which simply writes zeroes. As a result, enabling the test tags just gives a bunch of failed tests because they all look for the effective size on disk, that is, they assume the deallocated regions will become sparse. I don't really want to attempt to change the test suite to use a different filesystem (my FreeBSD test runner is already in tenuous shape as it is).

But, tmpfs(5) does support VOP_DEALLOCATE, so we can faff around a bit to try and prove it that way.

Lets make a tmpfs, and then make a file full of data:

$ mkdir /tmpfs
$ mount -t tmpfs tmpfs /tmpfs
$ dd if=/dev/random of=/tmpfs/file bs=100M count=1

Because its full of data, its effective size is 100K 1K-blocks:

$ du -s /tmpfs/file
102400	/tmpfs/file

I wrote a daft little program, dumpholes, to show the data/hole structure of a file. That also shows that it's all-data:

$ dumpholes /tmpfs/file
DATA 0
END 104857600

So we make a pool over the top, then issue the trim:

$ sudo zpool create tank /tmpfs/file
$ sudo zpool trim -w tank
$ zpool status -t
  pool: tank
 state: ONLINE
config:

	NAME           STATE     READ WRITE CKSUM
	tank           ONLINE       0     0     0
	 /tmpfs/file  ONLINE       0     0     0  (100% trimmed, completed at Sun Sep  1 13:29:55 2024)

errors: No known data errors

For extra fun, we can use dtrace to see that yes, its really doing things:

$ dtrace -n 'vfs::vop_deallocate:entry { ap = (struct vop_deallocate_args *)arg1; printf("off=%x len=%x", *ap->a_offset, *ap->a_len); }'
dtrace: description 'vfs::vop_deallocate:entry ' matched 1 probe
CPU     ID                    FUNCTION:NAME
  0  79177             vop_deallocate:entry off=410000 len=ff0000
  1  79177             vop_deallocate:entry off=1800000 len=c00000
  1  79177             vop_deallocate:entry off=2800000 len=c00000
  1  79177             vop_deallocate:entry off=3800000 len=c00000
  1  79177             vop_deallocate:entry off=4800000 len=c00000

After, we can see the effective size of the file has dropped, and its now full of holes:

$ du -s /tmpfs/file
36980	/tmpfs/file
$ dumpholes /tmpfs/file
DATA 0
HOLE 4313088
DATA 20971520
HOLE 25165824
DATA 37748736
HOLE 41943040
DATA 54525952
HOLE 58720256
DATA 71303168
HOLE 75497472
DATA 88080384
END 104857600

And if we read back part of the zeroed region, it is, indeed, zeroes:

$ xxd -a -s 0x4800000 -l 0xc00000 /tmp/file
04800000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
*
053ffff0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

So I suppose that works?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.